home *** CD-ROM | disk | FTP | other *** search
- Subject: FAQ 1: comp.software-eng questions and answers
- Newsgroups: comp.software-eng,comp.answers,news.answers
- From: dalamb@qucis.queensu.ca (David Alex Lamb)
- Date: 1 Nov 1994 15:38:03 GMT
-
- Last-Modified: 1 Nov 1994
- Archive-name: software-eng/part1
-
- This message gives brief answers to questions that have occurred in
- comp.software-eng; in many cases they are also topics many readers would like
- NOT to see discussed again soon. Questions are:
- What's a CASE Tool?
- What's a 'function point'?
- What's the 'spiral model'?
- What is a 'specmark'?
- Where can I find a public-domain tool to compute metrics?
- How do I write good C style?
- What is 'Hungarian Notation'?
- Are lines-of-code (LOC) a useful productivity measure?
- Should software professionals be licenced/certified?
- How do I get in touch with the SEI?
- What is the SEI maturity model?
- Where can I get information on API?
- What's a 'bug'?
- Where can I get copies of standards??
-
-
-
- ------------------------------------------------------------------------
- Subject: What's a CASE Tool?
- Date: 27 Oct 1994
- Archive file: casemsg (thanks to Scott McGregor <mcgregor@netcom.com> for
- inspiring this question)
-
- CASE stands for Computer Aided Software Engineering; it can be used to mean
- any computer-based tool for software planning, development, and evolution.
- Various people regularly call the following 'CASE': Structured Analysis (SA),
- Structured Design (SD), Editors, Compilers, Debuggers, Edit-Compile-Debug
- environments, Code Generators, Documentation Generators, Configuration
- Management, Release Management, Project Management, Scheduling, Tracking,
- Requirements Tracing, Change Management (CM), Defect Tracking, Structured
- Discourse, Documentation editing, Collaboration tools, Access Control,
- Integrated Project Support Environments (IPSEs), Intertool message systems,
- Reverse Engineering, Metric Analyzers.
-
-
- ------------------------------------------------------------------------
- Subject: What's a 'function point'?
- Date: 31 Jul 1993
- Archive file: funcpoints
-
- Function points and feature points are methods of estimating the "amount of
- functionality" required for a program, and are thus used to estimate project
- completion time. The basic idea involves counting inputs, outputs, and other
- features of a description of functionality. If interested, for a fee you can
- join:
- International Function Point Users Group
- 5008-28 Pine Creek Drive
- Blendonview Office Park
- Westerville, Ohio 43081-4899
-
-
- ------------------------------------------------------------------------
- Subject: What's the 'spiral model'?
- Date: 27 Oct 1994
- Archive file: spiral
-
- (1) Barry Boehm, "A Spiral Model of Software Development and Enhancement",
- ACM SIGSOFT Software Engineering Notes, August 1986.
- (2) Barry Boehm "A Spiral Model of Software Development and Enhancement"
- IEEE Computer, vol.21, #5, May 1988, pp 61-72.
-
- Basically, the idea is incremental development, using the waterfall model for
- each step; it's intended to help manage risks. Don't define in detail the
- entire system at first. The developers should only define the highest
- priority features. Define and implement those. With this knowledge, they
- should then go back to define and implement more features in smaller chunks.
-
-
- ------------------------------------------------------------------------
- Subject: What is a 'specmark'?
- Date: 27 Oct 1994
- Archive file: specmark
-
- The SPECmark is the geometric mean of a series of benchmarks done by the SPEC
- group. There are a couple of suites, but in general SPECmark refers to the
- results of the first suite. The suite includes FORTRAN and C codes, mostly
- well known codes but slightly hacked versions.
- SPEC
- c/o NCGA
- 2722 Merrilee Drive, Suite 200
- Fairfax, VA 22031
- Phone: (703) 698-9600
- FAX: (703) 560-2752
-
-
- ------------------------------------------------------------------------
- Subject: Where can I find a public-domain tool to compute metrics?
- Date: 27 Oct 1994
- Archive file: static.html
-
- Volume 20 of newsgroup comp.sources.unix contained a public-domain package
- called "metrics", which computes McCabe and Halstead metrics. There are many
- comp.sources.unix archives around the net.
-
-
- ------------------------------------------------------------------------
- Subject: How do I write good C style?
- Date: 27 Oct 1994
-
- This is answered regularly in the comp.lang.c FAQ. Try "Recommended C style
- and Coding Standards", via anonymous FTP to site archive.cis.ohio-state.edu in
- directory pub/style-guide
-
-
- ------------------------------------------------------------------------
- Subject: What is 'Hungarian Notation'?
- Date: 27 Oct 1994
- Archive file: hungarian
-
- A naming convention for C code. See Charles Simonyi and Martin Heller, "The
- Hungarian Revolution", BYTE, Aug. 1991 (vol. 16, no. 8). There are other
- naming conventions; see, e.g. "A Guide to Natural Naming", Daniel Keller,
- ETH, Projekt-Zentrum IDA, CH-8092 Zurich, Switzerland. Published in SIGPLAN
- Notices, Vol. 25, No. 5, pages 95-102.
-
-
- ------------------------------------------------------------------------
- Subject: Are lines-of-code (LOC) a useful productivity measure?
- Date: 27 Oct 1994
- Archive file: static.html
-
- Not unless you are very careful. Capers Jones' book has a detailed and
- insightful discussion of Lines of Code, including anomalies, and shows how to
- use it sensibly (eg in a single job shop, with a single language, and a
- standard company coding style). It is easy to cook up anomalies where LOC
- gives different numbers for code written in different styles, but pathological
- cases should get caught in code inspections. References:
- - T. Capers Jones, Programming Productivity, McGraw-Hill, New York, 1986
- - Capers Jones, Applied Software Measurement: Assuring Productivity and
- Quality, McGraw-Hill, Inc., 1991, 494 pages ISBN 0-07-032813-7
-
- The appendices of the latter give rules for counting procedural source code,
- as well as rules for counting function points and feature points. The
- following study, cited in Boehm's _S_o_f_t_w_a_r_e _E_n_g_i_n_e_e_r_i_n_g _E_c_o_n_o_m_i_c_s, claims that
- anomalies that seriously "fool" the LOC metric show up rarely in real code.
- - R. Nelson _S_o_f_t_w_a_r_e _D_a_t_e _C_o_l_l_e_c_t_i_o_n _a_n_d _A_n_a_l_y_s_i_s _a_t _R_A_D_C, Rome Air
- Development Center, Rome, NY. 1978.
-
-
- ------------------------------------------------------------------------
- Subject: Should software professionals be licenced/certified?
- Date: 27 Oct 1994
-
- This is a very controversial and political question. Generally, certification
- is something voluntary, while licencing is regulated by governments.
- Certification generally means some agency warrants you meet its standards;
- licencing generally means that to claim to practice a certain profession
- requires a government licence, often administered through a professional
- organization. In theory both are supposed to help judge if someone is capable
- of doing certain jobs.
-
- Licencing isn't currently required for computing professionals; some people
- would like to see some jobs require it, as with established branches of
- engineering. Others don't like government intervention, and/or believe many
- people who wouldn't get licenced are perfectly competent.
-
- Computing professionals in the USA have had a certification program for years,
- administered by the Institute for Certification of Computer Professionals
- (708-299-4227), a meta-organization with representatives from ACM, IEEE-CS,
- ADAPSO, ICCA, IACE, AIM, DPMA, AISP, COMMON, ASM, CIPS, and AWC. There are
- three certificates aimed at different broad types of practitioner, and many
- areas of specialization. To keep a certificate requires at least 40 hours of
- continuing education each year; credit can also be obtained for self-study,
- teaching, publication, etc.
-
-
- ------------------------------------------------------------------------
- Subject: How do I get in touch with the SEI?
- Date: 27 Oct 1994
-
- Try using the World-Wide Web via URL http://www.sei.cmu.edu/. For general
- information about the SEI, contact the customer relations department of the
- Software Engineering Institute at:
- internet: customer-relations@sei.cmu.edu
- Phone: (412) 268-5800
- A subscriber service is available to U.S. mailing addresses. Subscribers
- receive the SEI quarterly newsletter, Bridge; invitations to SEI public
- events; and first notification of course offerings and new publications. To
- become a subscriber, contact Customer Relations.
-
- To order an SEI publication, contact NTIS, DTIC, or RAI directly:
- National Technical Information Service (NTIS)
- U.S. Department of Commerce
- Springfield, VA 22161-2103
- Telephone: (703) 487-4600
-
- Defense Technical Information Center (DTIC)
- ATTN: FDRA Cameron Station
- Alexandria, VA 22304-6145
- Telephone: (703) 274-7633
-
- Research Access Inc. (RAI)
- 3400 Forbes Avenue
- Suite 302
- Pittsburgh, PA 15213
- Telephone: (412) 682-6530
- FAX: (412) 682-6530
-
-
- ------------------------------------------------------------------------
- Subject: What is the SEI maturity model?
- Date: 31 Jan 1992
- Originally-From: mcp@sei.cmu.edu (Mark Paulk)
- Archive file: maturity
-
- Maturity is not an easy concept to get down to a single paragraph, but
- consider this.
-
- Premise: The quality of a software system is largely governed by the quality
- of the process used to develop and maintain the software. Basics: The first
- step in improving the existing situation is to get management buy-in and
- management action to clean up the software management processes (walk the
- talk, as TQMers frequently say). Integration: The second step is to get
- everyone working together as a team. Measurement: The third step is to
- establish objective ways of understanding status and predict where things are
- going in your process. Continuous improvement: Understand that this is
- building a foundation for continually getting better.
-
-
- ------------------------------------------------------------------------
- Subject: Where can I get information on API?
- Date: 31 Oct 1994
-
- API stands for Application Programming Interface. For a useful subset of
- standard APIs that NIST considers relevant to US Federal government needs, you
- can look at NIST SP 500-187 "Application Portability Profile," using the
- World-Wide Web via URL http://nemo.ncsl.nist.gov/app-ose/, or send mail to
- mail-server@nemo.ncsl.nist.gov with
- send app-ose/app2.txt
- in the body, or contact Barbara Blickenstaff, 301-975-2816. Many of the open
- systems APIs are being developed in the IEEE POSIX groups. An article in the
- Dec. 1991 IEEE Spectrum describes these and related API standards. IEEE
- standards aren't distributed electronically, but both of the documents above
- tell how to obtain copies.
-
-
- ------------------------------------------------------------------------
- Subject: What's a 'bug'?
- Date: 12 May 1992
-
- You can take your pick:
- (1) Don't use "bug", use "fault" (an incorrect instruction or definition),
- "failure" (an incorrect result), or "mistake" (a human action leading
- to a failure). Paraphrased from
- IEEE Standard Computer Dictionary
- Standard 610, ISBN 1-55937-079-3
- Institute of Electrical and Electronic Engineers, Inc.
- 345 East 47th Street
- New York, NY 10017-2394 USA
- $49.50 (US$) for IEEE members
- (2) Beizer, in a footnote on page 33 of the second edition of _S_o_f_t_w_a_r_e
- _T_e_s_t_i_n_g _T_e_c_h_n_i_q_u_e_s says (paraphrased):
- I'm sticking with "bug" because everyone knows what it means,
- there are several "standards" for other terms that are incon-
- sistent with each other, the OED says that the conventional
- computer meaning of "bug" is ancient, and short Anglo-Saxon
- words are preferable to long Norman ones.
-
-
- ------------------------------------------------------------------------
- Subject: Where can I get copies of standards??
- Date: 28 Oct 1994
-
- ISO, ANSI, and IEEE standards are usually sold to raise some of the funds
- that the various national and international standards bodies (who usually
- own the copyright) need to keep afloat; thus they are not normally avail-
- able electronically. Also, the organizations are concerned that electron-
- ic copies would make it too easy for people to disseminate doctored ver-
- sions of the standards.
-
- ISO standards may be purchased from:
- In Canada:
- Standards Council of Canada / Conseil canadien des normes
- 1200-45 O'Connor,
- Ottawa K1P 6N7
- Phone: (613) 238-3222
- Fax: (613) 995-4564
- On CD-ROM:
- Omnicom, Inc.
- 115 Park St. SE
- Vienna, VA 22180-4607
- 1-800-OMNICOM
- Also available through the National Technical Information Service
- (NTIS), 5284 Port Royal Rd., Springfield, VA 22161, (703)
- 487-4650.
- ANSI and ANSI equivalent ISO standards are available from
- ASQC Quality Press
- Customer Service Department
- P.O. Box 3066
- Milwaukee, WI 53201-3066
- Voice: (800) 248-1946
- FAX: (414) 272-1734
-
- For ITU (formerly CCITT) standards, see the ITU using the World-Wide Web via
- URL gopher://info.itu.chor use their mail server: mail to itudoc@itu.ch with
- no subject and the following body:
- START
- HELP
- END
- There were once some CCITT standards on-line at the University of Colorado,
- but the arrangement to make them available via the Internet was terminated at
- the end of 1991.
- --
- Software Technology Laboratory dalamb@qucis.queensu.ca (David Alex Lamb)
- Computing and Information Science phone: (613) 545-6067
- Queen's University, Kingston, Ontario, Canada K7L 3N6
-
-